Master data management system for centrally managing core reference data associated with an enterprise

ABSTRACT

In one embodiment, a system is provided for centrally managing core enterprise reference data associated with an enterprise. A centralized master repository contains the core enterprise reference data. An internal services framework coupled to the centralized master repository provides a business process toolkit for managing models associated with the system. The business process toolkit includes a model library containing data models and one or more modeling services for modeling the system, its structure, and its components. The internal services framework also provides internal services for managing the core enterprise reference data within the centralized master repository, one or more of the internal services having direct access to the core enterprise reference data stored in the centralized master repository for management purposes. An infrastructure services layer coupled to the centralized master repository provides for bulk data transfers of core enterprise reference data between the centralized master repository and one or more external operational systems according to one or more enterprise-level business workflows, the external operational systems being permitted indirect access to the core enterprise reference data stored in the centralized master repository for operational purposes.

RELATED APPLICATIONS

[0001] This application is a continuation of application Ser. No.10/755,437 entitled “Master Data Management System for CentrallyManaging Core Reference Data associated with an Enterprise,” filed Jan.12, 2004, now pending.

TECHNICAL FIELD OF THE INVENTION

[0002] This invention relates generally to enterprise managementsolutions, and more particularly to a master data management system usedfor centrally managing core reference data associated with anenterprise.

BACKGROUND

[0003] An enterprise may use a data management system to addressmanagement of enterprise data. A considerable amount of data is requiredto adequately define an enterprise. The data may be of two fundamentaltypes. A first type of data, which may be referred to as core enterprisereference data, describes the structure and characteristics of theenterprise and its entities and is not transient or transactional innature. This type of data may be associated with enterprise data mastersand may be stored in a core reference data repository, although suchdata is not restricted to the type of data associated with traditionalenterprise data masters. Efficient handling this data is critical, as isorderly and process-driven management of the state of the data. Use ofthis data is, in general, not limited to particular portions of theenterprise; rather, this data is typically used pervasively throughoutthe enterprise and with its value chain partners. The second type ofdata, which may be referred to as operational data, is transienttransactional data required by planning, execution, monitoring, or otherenterprise solution components. This type of data is typically notstored in the core reference data repository; the data management systemprovides a staging and distribution framework for such data. A problemfacing many enterprises is to create a system that provides foreffective and scalable management, distribution, and use of both itscore enterprise reference data and its transactional data in a mannerthat services needs for this data within the enterprise as a whole andalso specific needs of planning, execution, monitoring, and otherenterprise solution components associated with the enterprise.

SUMMARY OF THE INVENTION

[0004] In one embodiment, a system is provided for centrally managingcore enterprise reference data associated with an enterprise. Acentralized master repository contains the core enterprise referencedata. An internal services framework coupled to the centralized masterrepository provides a business process toolkit for managing modelsassociated with the system. The business process toolkit includes amodel library containing data models and one or more modeling servicesfor modeling the system, its structure, and its components. The internalservices framework also provides internal services for managing the coreenterprise reference data within the centralized master repository, oneor more of the internal services having direct access to the coreenterprise reference data stored in the centralized master repositoryfor management purposes. An infrastructure services layer coupled to thecentralized master repository provides for bulk data transfers of coreenterprise reference data between the centralized master repository andone or more external operational systems according to one or moreenterprise-level business workflows, the external operational systemsbeing permitted indirect access to the core enterprise reference datastored in the centralized master repository for operational purposes.

[0005] Particular embodiments of the present invention may provide oneor more technical advantages. For example, certain embodiments mayprovide an enterprise framework incorporating classification intoconfiguration, planning, execution, and monitoring segments. Certainembodiments may provide a secure system of record optimized inarchitecture and design for management of core enterprise referencedata. Certain embodiments may allow for full or partial automation ofimportant time- and labor-intensive business processes according toembedded enterprise-level business workflows. Certain embodiments mayprovide all, some, or none of these technical advantages. Certainembodiments may provide one or more other technical advantages, one ormore of which may be readily apparent to those skilled in the art fromthe figures, description, and claims included herein.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] To provide a more complete understanding of the present inventionand the features and advantages thereof, reference is made to thefollowing description taken in conjunction with the accompanyingdrawings, in which:

[0007]FIG. 1 illustrates an example enterprise application frameworkincluding an MDM system;

[0008]FIG. 2 illustrates an example high level logical businessarchitecture for an MDM system;

[0009]FIG. 3 illustrates an example high level logical technicalarchitecture an MDM system;

[0010]FIG. 4 illustrates an example high level logical data servicesarchitecture for an MDM system;

[0011]FIG. 5 illustrates an example high level logical architecture ofan MDM database;

[0012]FIG. 6 illustrates an example information sharing architecture foran MDM system;

[0013]FIG. 7 illustrates an example MDM studio and an associated MDMmodel library;

[0014]FIG. 8 illustrates an example MDM use model;

[0015]FIG. 9 illustrates an example high level physical architecture foran MDM system; and

[0016]FIG. 10 illustrates an example new item introduction processprovided within an MDM system.

DESCRIPTION OF EXAMPLE EMBODIMENTS

[0017] I. Enterprise Solution Framework

[0018]FIG. 1 illustrates an example enterprise solution framework 2including an MDM system 4. In one embodiment, framework 2 includes aclassification of an associated enterprise into four fundamentalsegments: (1) configuration of the enterprise and its entities; (2)planning with respect to the enterprise and its entities; that is,decisions about what to do; (3) execution with respect to the enterpriseand its entities; that is, acting upon those decisions; and (4)monitoring with respect to the enterprise and its entities; that is,monitoring the results of those decisions and supplying feedback to theconfiguration and planning segments accordingly. In this embodiment, MDMsystem 4 represents the configuration segment, while the planning,execution, and monitoring enterprise solution components 6 represent theplanning, execution, and monitoring segments, respectively.

[0019] MDM system 4 provides centralized storage and management ofenterprise reference data, maintaining reference data and associateddata management processes separate from enterprise solution components 6and associated operational processes while making reference dataavailable to enterprise solution components 6 for consumption as needed.Centralized storage and management of reference data for existing andfuture enterprise solution components 6 may facilitate extension orother modification of enterprise solution components 6 without needingto modify reference data within MDM system 4. Centralized storage andmanagement of reference data may also facilitate integration ofenterprise solution components 6, for example, when one enterprisesolution component 6 is replaced with another or an enterprise solutioncomponent providing an entirely new business function is introduced.Centralized storage and management of reference data may furtherfacilitate integration of one enterprise into another, for example, inconnection with a merger or acquisition.

[0020] Infrastructure services 8 provide bulk data transfer andenterprise messaging between MDM system 4 and enterprise solutioncomponents 6 in accordance with business workflows operating inassociation with infrastructure services 8. These workflows, which maybe embedded partially within MDM system 4 and partially withininfrastructure services 8, may incorporate customized business bestpractices of the enterprise. In addition, these workflows may be whollyor partially automated using an appropriate enterprise-level workflowengine and appropriate MDM system resources available to that workflowengine.

[0021] II. MDM Logical Business Architecture

[0022]FIG. 2 illustrates an example high level logical businessarchitecture 10 for an MDM system 4. In general, the logical businessarchitecture represents a business-centric view of MDM system 4 andincludes core business processes, services, and data elements that MDMsystem 4 may be required to provide depending on the nature of theenterprise associated with MDM system 4. In one embodiment, MDM system 4includes a process layer 12 that provides a context for implementing andwholly or partially automating business configuration processes 14. Aservice layer 16 underlying process layer 12 provides services 18providing functions enabling process tasks that are appropriate forprocesses 14. A data layer 20 underlying service layer 16 provides basedata models and physical representations for storing core enterprisereference data 22 for retrieval and use in connection with processes 14and associated services 18.

[0023] An understanding of the fundamental concepts relating to thepurposes and functions of MDM system 4 may aid in understanding the MDMarchitecture. At the core of MDM system 4 is the concept of datamanagement, which encompasses both what data is stored and how that datais stored and made available for use. Since MDM system 4 is primarilyconcerned with structural data describing the enterprise or, moreprecisely, with data associated with entities within the businessstructure of the enterprise, the focus of the MDM architecture is on thestorage, management, and retrieval of data associated with entities orwith relationships between entities. In one embodiment, MDM system 4provides such data storage, management, and retrieval using a core MDMreference data repository based on a multi-dimensional databaseconstruct.

[0024] Consider the following example. One example of an entityassociated with a retail enterprise is an item. Items may haveattributes such as size, weight, color, etc. If a particular entity, inthis case a particular item, is considered a coordinate in a firstdimension representing items, then the attributes of the particular itementity are associated with the coordinate for the particular item in theitem dimension. At this point, the example involves only aone-dimensional line space, where discrete points on the line representparticular items.

[0025] Another example of an entity associated with an enterprise is astore or other location. Locations may have attributes such as size,physical address, etc. Like the particular item discussed above, aparticular location may be considered a coordinate in a second dimensionrepresenting locations, where the attributes of the particular locationentity are associated with the coordinate for the particular location inthe location dimension. At this point, the example involves twoone-dimensional line spaces, where discrete points on the first linerepresent particular items and discrete points on the second linerepresent particular locations. The example may be extended to includeattributes that depend on the combination of a particular item and aparticular location. Neither the item dimension nor the locationdimension alone will suffice to store such multi-dimensional attributes.However, if the item and location dimensions are viewed as axes, andeach intersection of item and location coordinates within an areadefined by an orthogonal arrangement of these axes is viewed as a (item,location) point in two-dimensional entity space at which such attributesare stored, the concept becomes clear.

[0026] The example can be further extended to include attributes thatdepend on the combination of any number of arbitrary entity dimensions,leading to the concept of attributes as generalized data stored at andretrieved from points in an n-dimensional entity space. For example, aparticular three-dimensional entity space suitable for an example retailenterprise might include item, location, and time dimensions, whereattributes stored at each (item, location, time) point within a volumedefined by an orthogonal arrangement of these axes corresponds to aparticular combination of entities in the item, location, and timedimensions. In one embodiment, all reference data 22 stored within MDMsystem 4 may be equivalent to an attribute associated with a point inn-dimensional entity space.

[0027] In one embodiment, an overriding characteristic of all data thatis considered for inclusion within MDM system 4 is the multi-dimensionaldatabase construct described above. Hence, a core architecturalprinciple for MDM system 4 may be to accommodate a dimensional datastructure as a core element in every component of MDM system 4. This mayhave several important implications for the MDM architecture and design.Such important implications may include, without limitation: (1) aconsistent mechanism for locating points in an n-dimensional entityspace; (2) a consistent mechanism for storing data at and retrievingdata from points in an n-dimension entity space; and (3) ensuring thatall distinct data storage components support the above.

[0028] Another fundamental concept for MDM system 4 may involveoptimization of the physical architecture and database structures forthe desired functions of MDM system 4. The core MDM reference datarepository, as described above, is primarily for data management and isstructured to provide a rich data management framework. On the otherhand, input and output data staging and distribution elements of MDMsystem 4 may require efficient data transfer and throughput. While manysystems have attempted to provide a compromise architecture to handleall such needs, MDM system 4 is preferably structured so that eachelement is designed to optimally accomplish its corresponding functions.

[0029] MDM system 4 may provide value for enterprises in variousindustry settings, such as retailing, manufacturing, or other industrysettings. Although retail examples may be provided for purposes ofillustration, the present invention contemplates MDM system 4 being usedin connection with, and being tailored to, any suitable enterprise. TheMDM architecture and design are preferably constructed to provideelements suitable to allow for successful deployment of MDM system 4across multiple industry types and multiple enterprises within aparticular industry type.

[0030] A. Process Layer

[0031] As described above, MDM system 4 includes a process layer 12 thatprovides the context for implementing and wholly or partially automatingbusiness configuration processes 14. In general, processes 14 providefunctions necessary to realize process workflows provided as part of theMDM solution, providing structure to enterprise activities and enablingthose activities to be repeated, controlled, monitored, and improvedover time. Each process 14 represents a sequence of tasks that togetheraccomplish a business activity. MDM system 4 may provide native supportfor generic processes 14 and support specific to particular processes14. In one embodiment, processes 14 allow rich business workflows to beembedded within MDM system 4 and supported using the resources withinunderlying service and data layers 16 and 20, respectively. In oneembodiment, MDM system 4 provides a highly configurable, flexible, andextensible environment for implementing and wholly or partiallyautomating any suitable processes 14.

[0032] Processes 14 may operate at two levels. The first level, theenterprise level, may include larger scale intra-enterprise andinter-enterprise processes 14 associated with management of data as itrelates to the targeted goals of the MDM solution. For example, whereMDM system 4 is associated with a retail enterprise, an example of afirst level process 14 may be a new item introduction process 14involving storage of externally generated data concerning a new iteminto the core MDM reference data repository. The second level mayinclude smaller scale management processes 14 involving movement of datainternal to MDM system 4, such as retrieval of data from the core MDMreference data repository in accordance with queries from userinterface, analytics, or other services internal to MDM system 4.

[0033] For example, generic processes 14 that may apply to anyenterprise and any dimension of MDM system 4 may include, withoutlimitation: (1) new entity introduction; (2) entity maintenance; (3)metadata realignment; (4) entity extraction; and (5) entity replication.

[0034] 1. New Entity Introduction

[0035] This process 14 represents the introduction of a new entity intoMDM system 4. For an example retail enterprise, this may includeintroducing a new item, location, vendor, or customer. The process 14may be initiated by the enterprise associated with MDM system 4 or byany other enterprise, such as a vendor of a new item being introduced. Avendor providing a new item may be considered an example of contentexchange. In any case, the retail enterprise associated with MDM system4 must add enterprise specific data to MDM system 4 for the new item,validate the data, approve use of the new item, and publish the new itemas available for use by planning, execution, monitoring, or otherenterprise solution components 6, possibly through replication. Anexample new item introduction process 14 is described more fully belowwith reference to FIG. 10.

[0036] 2. Entity Maintenance

[0037] This process 14 involves updating one or more characteristics ofan existing entity, such as an item, location, vendor, or customer foran example retail enterprise. The process 14 may be initiated by theenterprise associated with MDM system 4 or by any other enterprise, suchas a vendor of an item for which one or more characteristics are to beupdated. For example, an “improved” item may effectively retain itsoriginal part number and Stock Keeping Unit (SKU) but have one or moreof its primary attributes altered by the vendor, such as its size,weight, or color. Similarly, the retail enterprise might alter one ormore secondary attributes of an existing item.

[0038] 3. Metadata Realignment

[0039] This process 14 involves movement within a dimension of one ormore members of one level relationship to another level relationship ina dimensional hierarchy. For example, a retail enterprise might move anitem from one class to another class, which would in turn requireidentification of the one or more members to alter and the targetrelationships. The process 14 may need to keep appropriate audit andjournal trails may require one or more approval sub-processes.

[0040] 4. Entity Extraction

[0041] This process 14 involves providing selection criteria for one ormore entities, performing an appropriate query, and moving appropriatedata or otherwise making the data available to the requesting role orsubsystem.

[0042] 5. Entity Replication

[0043] This process 14 involves systematic replication of data in MDMsystem 4 in whole or in part to other subsystems for internal use. Suchreplication may allow the data to be used in a more efficient fashionthan through direct operational access to the core MDM reference datarepository.

[0044] B. Service Layer

[0045] As described above, service layer 16 provides services 18 thatprovide functions enabling the construction of process tasks appropriatefor processes 14. Each service 18 provides a useful unit of work orenables a process task in the context of MDM system 4. Services 18 arenot processes 14; rather, a service 18 is more analogous to a taskwithin a process 14 or an action in response to a request associatedwith a process 14, such as computing the value of a function associatedwith the service 18 or issuing a query to view, update, or deleteinformation in the core MDM reference data repository. In oneembodiment, services 18 within service layer 16 of MDM system 4 for anexample retail enterprise may include, without limitation: (1) entitymaintenance services 18 a; (2) metadata maintenance services 18 b; (3)parameter maintenance services 18 c; (4) attribute/trait services 18 d;(5) event (calendar) services 18 e; (6) supply chain network services 18f; (7) sourcing services 18 g; (8) activity based costing (ABC) services18 h; (9) contract services 18 i; and (10) bill of materials (BOM)services 18 j.

[0046] 1. Entity Maintenance

[0047] Entity maintenance services 18 a provide basic functions fornavigating, accessing, filtering, and sorting entities within MDM system4. For an example retail enterprise, items, locations, vendors, andcustomers may be types of entities that are managed within MDM system 4and maintained using entity maintenance services 18 a.

[0048] 2. Metadata Maintenance

[0049] Metadata maintenance services 18 b provide basic functions forthe construction, management, and realignment of appropriate metadata.For example, such metadata may include metadata describing theenterprise as a whole, the structure of MDM system 4, the structures ofthe data staging areas of MDM system 4, and the relationships betweenthe data staging areas and the core MDM reference data repository. Suchfunctions may include the ability to create dimensions and to definehierarchies on the dimension spaces, where each hierarchy includes anumber of levels each having a number of members. Such functions mayalso include maintenance with respect to dimensions, levels, andmembers, such as creation, modification, or deletion of such metadataelements.

[0050] 3. Parameter Maintenance

[0051] Parameter maintenance services 18 c provide basic functions forthe maintenance, management, and distribution of enterprise solutioncomponent parameters (i.e. business rule parameters). One or moreparameters may be, but are not required to be, specific to one or moreparticular enterprise solution components 6. Each parameter may be tiedto one or more entities and, as such, may be viewed as a secondaryattribute of the entities (as opposed to a primary attribute such assize, weight, and color of an example item). Parameter maintenanceservices 18 c provide functions particularly appropriate for these typesof attributes. MDM system 4 may not only provide storage for suchattributes and enable retrieval of such attributes for use, but may alsoprovide a standardized management paradigm for all parameters in theoverall enterprise solution. In one embodiment, this has the beneficialeffect of providing a uniform methodology for parameter management andrelieves point solution components from providing such functionality.

[0052] 4. Attribute/Trait Services

[0053] Some attributes of entities are quantitative, well-defined, andstable over time. Examples of such attributes might include the size,weight, and color of an item or the address of a vendor. Other types ofattributes are more qualitative, not as well-defined, and may changeover time. These attributes, which may be referred to as traits, areoften useful for customer-centric marketing and serve as the basis forattribute/trait cluster generation. Attribute/Trait services 18 dprovide functions appropriate for this type of data residing within ormanaged using MDM system 4. Since the number, and even the types, ofsuch attributes/traits are typically not known a priori, therequirements for the physical structure of a system to handle this typeof data are somewhat different than for more static master data.Attribute/Trait services 18 d provide basic functions for creating,maintaining, and using this type of data and may also include moresophisticated services such as attribute/trait clustering services.

[0054] 5. Event (Calendar) Services

[0055] Event, or more generally calendar, services 18 e deal withmanagement of time-related activities. These services 18 e provide basicfunctions for establishing reference calendars and for creating andmanaging time-related activities (i.e. events with respect toestablished calendars).

[0056] 6. Supply Chain Network Services

[0057] Supply chain network services 18 f provide basic functions forsupporting the definition and use of the physical supply chain networkassociated with an enterprise. The supply chain network is crucial tomany planning, execution, monitoring, and other enterprise solutioncomponents 6 supported using MDM system 4.

[0058] 7. Sourcing Services

[0059] Sourcing services 18 g provide basic functions for accessing andusing elements of the MDM model that are relevant to sourcing solutioncomponents, such as a supplier relationship management solutioncomponent.

[0060] 8. Activity Based Costing (ABC) Services

[0061] A number of useful measures may be associated with entities, suchas items where MDM system 4 is associated with a retail enterprise, thattraditionally have not been associated with an item catalog or similarconstruct. These measures may enable useful advanced analysis. Oneexample is cost and price data associated with items. Such data may beused for advanced pricing optimization and ABC analyses. In oneembodiment, MDM system 4 provides models to capture cost data, such ascost elements that when aggregated represent the total landed cost ofgoods. Included in these models are costs associated with activitiessuch as handling an item as it passes through points in the associatedsupply chain network. ABC services 18 h provide basic functions forhandling ABC data stored within and managed using MDM system 4.Moreover, data such as normalized demand profiles (or associations tosuch profiles) are examples of secondary attributes that MDM system 4may need to be accommodate.

[0062] 9. Contract Services

[0063] In one embodiment, MDM system 4 does not inherently create ormanage contracts for an example retail enterprise. However, MDM system 4preferably provides a repository for contract data as it relates toentities stored within MDM system 4 and provides a centralizeddistribution mechanism for contract data to appropriate enterprisesolution components 6. Contract services 18 i provide basic functionsfor inputting, associating, and distributing contract-related datarelated to core enterprise data residing within MDM system 4.

[0064] 10. Bill of Materials (BOM) Services

[0065] For an example retail enterprise, BOM services 18 j provide basicfunctions for creating, managing, and visualizing BOMs for theenterprise. For example, a single actual BOM may be too atomic forplanning purposes, such that suitable aggregation of one or more actualBOMs into a representation appropriate for planning may be required tosupport a planning system associated with MDM system 4. MDM system 4 maystore such representations as reference data and make them available toplanning or other external operational systems as needed. MDM system 4may also automatically generate such representations, based on a MDM BOMmodel, to reduce or eliminate the need for manual evaluation andaggregation of individual actual BOMs to order to create suchrepresentations. BOM services 18 j preferably support the elements ofany appropriate MDM BOM model.

[0066] C. Data Layer

[0067] MDM system 4 is fundamentally concerned with the ability tocreate, manipulate, and extract data associated with the enterprisesolution. As described above, data layer 20 provides the base datamodels and physical representations for storing various types ofenterprise reference data 22 for retrieval and use in connection withprocesses 14 and associated services 18. In one embodiment, referencedata 22 within data layer 20 of MDM system 4 for an example retailenterprise may include, without limitation: (1) master data 22 a; (2)metadata 22 b; (3) enterprise models 22 c; (4) parameter data 22 d; (5)attribute/trait data 22 e; (6) event (calendar) data 22 f; (7) supplychain network data 22 g; and (8) ABC data 22 h.

[0068] 1. Master Data

[0069] Master data 22 a represents core configuration data associatedwith entities, such as items, locations, vendors, and customers for anexample retail enterprise. Many aspects of value chain managementgenerally, and most planning, execution, monitoring, or other enterprisesolution components 6 in particular, require reference data 22 regardingwhat items are sold, what locations sell the items, what vendors supplythe items, what customers purchase the items, and other fundamental dataelements on which all other enterprise data is built or to which allother enterprise data relates in some manner. MDM system 4 may extendthe traditional concept of master data with respect to such entities toaccommodate complex business workflows envisioned for an enterprisesolution. Although legacy masters, for example item masters, may captureattributes of items such as SKUs that indicate where the items fit intothe hierarchical structure of the enterprise data, there is no guaranteethat a legacy system could manipulate or even view such data in adimensional sense. In one embodiment, an item or other master for MDMsystem 4 is able to create, manipulate, navigate, view, and extract datain a dimensional way.

[0070] In one embodiment, an entity within a master data type representsan atomic member of that type, such as a particular item, a particularlocation, a particular vendor, or a particular customer. Attributes ofentities such as items, locations, and the like may have important roleswith respect to planning, execution, monitoring, and other enterprisesolution components 6. A first type of entity attribute is a physical orprimary attribute generally associated with inherent characteristics ofthe entity, such as size, weight, and color for an example item entity.Primary attributes may be very important, for example, in planningproduct assortments or solving logistics problems associated withshipping an order for an item. Primary attributes are reasonably staticand require no other context for meaning than the associated entityitself. A second type of entity attribute exists as a consequence of theuse of the entity within the enterprise, which may result in a definedrelationship of the entity to another entity or to an external metric.An example of such as attribute of an item might be the category orsub-category within the enterprise to which the item is assigned. Thistype of attribute, often referred to as a qualitative or secondaryattribute, may be very important for more advanced analytic techniquessuch as item grouping/clustering, customer focused marketing, andpromotions. In one embodiment, master data 22 a allows MDM system 4 tomanage both primary and secondary attributes of entities.

[0071] It may be important to distinguish between data considered to bemaster data 22 a and data considered to be attribute/trait referencedata 22 e described below. As discussed above, master data 22 a may bereasonably static and may not change rapidly over time. For example, acolor (primary attribute) of a particular shirt may not change within aseason the shirt is sold. Although the sub-category within theenterprise to which the shirt is assigned (secondary attribute) maychange, as a result of a realignment for example, such changes willlikely be infrequent. In contrast, for example, attributes/trait data 22e may be heavily used for targeted assortment and hence must capturedynamic behaviors of customers. In addition, attributes/traits maythemselves change, with new attributes/traits being added as appropriateand existing attributes/traits which are no longer valid being droppedas appropriate.

[0072] 2. Metadata

[0073] Another form of reference data 22 that is inherent to the entitymasters described above and is very important to many enterprisesolution components 6 is enterprise metadata 22 b. In general, metadata22 b is data describing other data. In the context of MDM system 4,metadata 22 b describes the structure of the data stored in and managedusing MDM system 4. In general, metadata 22 b provides a description ofthe structure of the dimensional view of master data 22 a. Thisdescription focuses on what dimensions exist, what levels describe thedimension coordinates, and what members exist and are associated withthe levels. In addition, navigation constructs referred to ashierarchies may be defined. For example, for an example retailenterprise, metadata 22 b might include the various levels of thetaxonomy of items and one or more hierarchies for navigating through thevarious levels of the taxonomy. In one embodiment, MDM system 4 capturesmetadata 22 b in a form that can be effectively replicated to downstreamenterprise solution components 6 that require consistency in thedimensional view of master data 22 a. As described above in connectionwith metadata maintenance services 18 b, MDM system 4 may manage thecreation, manipulation, and deletion of metadata 22 b and provide forrealignment of master data 22 a (e.g. moving an item from a firstcategory to a second category) such that any realignment is properlyreflected in metadata 22 b.

[0074] 3. Enterprise Models

[0075] Enterprise models 22 c represent organizational views of theroles within an enterprise. In one embodiment, enterprise models 22 cmay extend beyond the enterprise boundary to cover all organizationalelements of the value chain associated with the enterprise. Enterprisemodels 22 c may be important with respect to authentication andauthorization aspects of data access. Additionally, enterprise models 22c may provide for approval chain relationships important to businessprocess management.

[0076] 4. Parameter Data

[0077] 5. Attribute/Trait Data

[0078] 6. Event (Calendar) Data

[0079] 7. Supply Chain Network Data

[0080] 8. Activity Based Costing (ABC) Data

[0081] III. MDM Logical Technical Architecture

[0082]FIG. 3 illustrates an example high level logical technicalarchitecture 30 for MDM system 4. In general, logical technicalarchitecture 30 represents a technology-centric view of MDM system 4 andspecifies logical elements of MDM system 4 that together may operate toprovide the desired MDM solution. In one embodiment, logical technicalarchitecture 30 includes an MDM services framework 32 containing coreMDM services 34. MDM database 36 includes the core MDM reference datarepository. Certain services 34 may be applied to any classes ofreference data 22 to be modeled within the core MDM reference datarepository. Other services 34 may be tailored to particular classes ofreference data 22 modeled within the core MDM reference data repository.Other services 34 may generically support various security, data access,data staging, and other data management needs. Example services 34 aredescribed more fully below. Appropriate services 34 may access database36 using one or more appropriate data access links 38.

[0083] External operational systems 40 may access database 36 using oneor more data access layers 42. In one embodiment, an externaloperational system 40 may access database 36 in connection with abusiness workflow using a “front side” data access layer 42 a, anassociated “front” bus 44 a between external operational system 40 andfront side data access layer 42 a, and an associated data interface 46 abetween front side data access layer 42 a and database 36. Front sidedata access layer 42 a is typically used to pass control data fromexternal operational systems 40 to MDM system 4 for controlling MDMoperations and may be associated with application integration. One ormore services 34 may access front-side data access layer 42 a using oneor more suitable data access links 48. An external operational system 40may access database 36 using a “back side” data access layer 42 b, anassociated “back” bus 44 b between external operational system 40 andback side data access layer 42 b, and an associated data interface 46 bbetween back side data access layer 42 b and database 36. Back side dataaccess layer 42 b is typically used for movement of reference data 22 toand from external operational systems 40 and may be associated with dataintegration. However, front side data access layer 42 a may also be usedto move reference data 22 to and from external operational systems 40where appropriate, for example, where an external operational system 40requires particular reference data 22 in a particular message-based orother format.

[0084] A. Logical Data Services Architecture

[0085]FIG. 4 illustrates an example high level logical data servicesarchitecture 50 for MDM system 4. In one embodiment, data servicesarchitecture 50 includes primary layers: (1) a “front side” dataservices layer 52 a; (2) a physical data layer 54; and (3) a “back side”data services layer 52 b. Front side data services layer 52 a isassociated with front side data access layer 42 a, described above withreference to FIG. 3, and provides direct data access to internal MDMservices 34 that directly access the core MDM reference data repositorywithin database 36. For example, front side data services layer 52 a mayprovide direct access to database 36 for internal analytics or userinterface service queries. Physical data layer 54 includes database 36in which the core MDM reference data model resides. Back side dataservices layer 52 b is associated with back side data access layer 42 b,described above with reference to FIG. 3, and provides indirect dataaccess to external operational services 56 associated with externaloperational systems 40 that indirectly access the core MDM referencedata repository within database 36. For example, back side data serviceslayer 52 b may provide operational services with indirect access todatabase 36 through staging areas of database 36, staging areasassociated with external operational systems 40, and persistent datastores associated with external operational systems 40. In a physicaldeployment, each of the three primary layers of data servicesarchitecture 50 may be mapped to appropriate technology components.

[0086] Front side data services layer 52 a may be mapped to anappropriate object-based services layer, such as Common Object RequestBroker Architecture (CORBA) or JAVA 2 PLATFORM ENTERPRISE EDITION(J2EE), residing on an appropriate application server within anapplication server layer (described below with reference to FIG. 9). Incertain embodiments, front side data services layer 52 a may be moretightly coupled to physical data layer 54 due to the necessity of anobject-to-relational translation layer as part of front side dataservices layer 52 a.

[0087] Database 36 within physical data layer 54 may be implemented as arelational database. Database 36 may be modeled and managed in a numberof ways, one of which may be selected for a particular deployment. Inone embodiment, object relational database management technology may beused, although this approach is typically subject to performance risks.With this approach, the core MDM reference data model may be mapped toexisting services 34 using a suitable object relational mapping layer.In an alternative embodiment, for improved performance or other reasons,a fixed data model relational database with a light access layer may beused. The light access layer would provide persistent objects tailoredto the fixed and optimized physical schema of the relational databaserather than driving the physical schema through an object relationalmapping layer. With this approach, new services 34 may be mapped to anexisting core MDM reference data model.

[0088] Although a single core MDM reference data repository within asingle database 36 is primarily described herein for convenience, thepresent invention contemplates any number of core MDM reference datarepositories within any number of databases 36 according to particularneeds. However, all core MDM reference data repositories within alldatabases 36 are subject to centralized data management associated witha single MDM system 4 and preferably appear to both internal MDMservices 34 and external operational services 56 as a single core MDMreference data repository.

[0089] Back side data services layer 52 b is preferably optimized forpotentially large data synchronization and replication operations,preferably incorporating net change techniques, efficient storeprocedure techniques, and an object-based control layer. Furthermore,since back side data services layer 52 b maps to planning, execution,monitoring, or other enterprise solution components 6 for which datamovements and associated mappings (i.e. transformations) must remainreasonably fixed over time, the core MDM reference data model shouldalso be reasonably fixed over time.

[0090] B. Logical Data Repository Architecture

[0091]FIG. 5 illustrates an example high level logical architecture 70of database 36. In one embodiment, database 36 incorporates a consistentdimensional modeling framework imposed on a model supporting apersistence management service, which is described more fully below.This preferably allows services framework 32 to manage reference data 22within database 36 in a manner that is consistent with establisheddimensional views of reference data 22. Where MDM system 4 does notphysically contain all reference data 22, reference data 22 that is notphysically contained in MDM system 4 preferably appears as if it isphysically contained in MDM system 4. Database 36 includes a manageddata area 72 containing reference data 22, at least some of which may bemanaged remotely from MDM system 4. Managed data area 72 provides thecore MDM reference data repository for reference data 22. Database 36may also include a cached data area 74 containing cached data 76representing reference data 22 that has been extracted from managed dataarea 72, processed according to the needs of one or more elements of MDMsystem 4 using a data management framework 78, and is re-inserted inmanaged data area 72 as reference data 22 once processing is complete.For example, data management framework 78 may provide the processcontroller within business process toolkit 34 a, UI services 34 d, orany other suitable element of MDM system 4 with operational access tocached data 76.

[0092] Reference data 22 stored within MDM system 4 has an assignedstate consistent with its use. In one embodiment, in association withdata management framework 78, cached data area 74 provides a mechanismto hold a copy of reference data 22 for manipulation while the state ofreference data 22 in managed data area 72 is maintained as locked forread only access until the manipulation process has completed. Once acopy of reference data 22 is being held as cached data 76 within cacheddata area 74 during the manipulation process, the manipulation processsees only the state of cached data 76 within cached data area 74, whileother processes, services, and systems associated with MDM system 4 seethe true state of reference data 22 within managed data area 72 ratherthan an intermediate state reflecting the still incomplete manipulationprocess.

[0093] Database 36 may also include an operational access area 80providing one or more external operational systems 40 with access toreference data 22 within managed data area 72. Where MDM system 4 isassociated with an example retail enterprise, external operationalsystems 40 may include external enterprises such as manufacturers,distributors, and vendors of items associated with enterprise. Externaloperational systems 40 may also include planning, execution, monitoring,and other enterprise solution components 6 within the enterprise butexternal to MDM system 4. Operational access area 80 may containing amaster copy 82 of an Lightweight Directory Access Protocol (LDAP)repository used to provide authentication and authorization services asdescribed more fully below. Operational access area 80 may also containinbound and outbound staging areas 66 and 68, respectively, for datathat is inbound from and outbound to, respectively, external operationalsystems 40.

[0094] C. Information Sharing Architecture

[0095] In one embodiment, data may enter MDM system 4 from anyappropriate source and may leave MDM system 4 for any appropriatetarget. Unless reference data 22 stored within the core MDM referencedata repository can be readily made available to external operationalsystems 40, storing reference data 22 within the core MDM reference datarepository may provide little value to the enterprise. Conversely, theremay be other data residing within portions of the enterprise that needsto be distributed to other portions of the enterprise through MDM system4. FIG. 6 illustrates an example information sharing architecture 90 forMDM system 4. In one embodiment, database 36 may be optimized formanagement of reference data 22 rather than for speed of data input ordata output. Accordingly, a staging strategy may be employed to minimizedata transfer times to and from external operational systems 40.

[0096] As described above, inbound data may be received from one or moredata sources 92 for storage in the core MDM reference data repository ofmanaged data area 72. Data sources 92 may include persistent data storesassociated with external enterprises 40 a, such as manufacturers,distributors, vendors, and customers where MDM system 4 is associatedwith an example retail enterprise. Data sources 92 may also includeoperational staging data stores associated with planning, execution,monitoring, or other enterprise solution components 6. The inbound datais first moved into inbound staging tables 94 of inbound staging area84, then into core MDM tables 96 within the core MDM reference datarepository of managed data area 72 as reference data 22. Data cleansing,validation, transformation, or other processing may occur, whereappropriate, during the movement of data from inbound staging area 84 tothe core MDM reference data repository managed data area 72. Forexample, it may be very important that reference data 22 stored withinthe core MDM reference data repository and made available to externaloperations systems 40 is considered clean, such data cleansing inconnection with loading of inbound data.

[0097] As described above, outbound data may be provided to one or moredata targets 98, such as persistent data stores associated with externalenterprises 40 a or operational staging data stores associated withplanning, execution, monitoring, or other external enterprise solutioncomponents 6. Outbound data being distributed using MDM system 4 withoutbeing stored in the core MDM reference data repository may be sent frominbound staging tables 94 of inbound staging area 84 to outbound stagingtables 100 a of uncoupled outbound staging area 86 a, then out to datatargets 98. Similarly, outbound reference data 22 in the core MDMreference data repository of managed data area 72 may be moved out ofcore MDM tables 96 of managed data area 72 to outbound staging tables100 b of coupled outbound staging area 86 b, then out to data targets98. Reference data 22 stored within core MDM tables 96 may besubstantially continuously synchronized with the outbound data inoutbound staging tables 100, such that at any point in time an accuratesnapshot of reference data 22 is available within outbound staging area86. Synchronization of reference data with operational data may beimportant, for example, to help ensure that planning based uponoperational data is not performed for an entity that no longer existswithin the enterprise as reflected in reference data 22. Datatransformation or other processing may occur, where appropriate, duringthe movement of reference data 22 from the core MDM reference datarepository of managed data area 72 to outbound staging area 86.

[0098] D. MDM Services Framework

[0099] Referring again to FIG. 3, in one embodiment, services framework32 may provide services 34 organized into the following groups, withoutlimitation: (1) business process toolkit 34 a, (2) security services 34b, (3) general services 34 c, (4) user interface services 34 d, (5) dataaccess services 34 e, and (6) data staging services 34 f.

[0100] 1. Business Process Toolkit

[0101] Business process toolkit 34 a may be provided using acorresponding subsystem within services framework 32 that provides formanagement of MDM models, processes, and associated business rules.Automated processes associated with this subsystem may be used toimplement model changes associated with physical deployment of MDMsystem 4. In one embodiment, business process toolkit 34 a may include,without limitation: (1) a MDM studio, (2) a MDM model library, (3) abusiness rules management service, (4) a process controller, and (5) aMDM structure update service.

[0102] a. MDM Studio & MDM Model Library

[0103]FIG. 7 illustrates an example MDM studio 110 and an associated MDMmodel library 112 containing one or more MDM models 114 appropriate forMDM system 4. MDM studio 110 may provide services to model the structureof MDM system 4 and its components, for example, for purposes ofconstructing MDM system 4 or for purposes of extending or otherwiseupdating MDM system 4. MDM studio 110 may provide support for one ormore graphical modeling user interfaces. Modeling of MDM system 4 mayinclude, for example, modeling structural aspects of the core MDMreference data repository within managed data area 72 of database 36,modeling the structure of staging areas 66 and 68 of database 36, andmodeling appropriate process workflows. MDM studio 110 may providesupport both for initial construction of MDM models 114 and laterextension or other updating of MDM models 114. In one embodiment, MDMmodels 114 include, without limitation: (1) MDM process model 114 a, (2)MDM document model 114 b, (3) MDM forms model 114 c, (4) MDM referencedata model 114 d, and (5) MDM staging data model 114 e.

[0104] (1) MDM Process Model

[0105] Process models 114 a describe the processes 14 to be used formanaging reference data 22 stored within the core MDM reference datarepository within database 36. In one embodiment, for a particularprocess 14, the corresponding process model 114 a describes the flow oftasks to be performed on reference data 22 in connection with process14, particular services 18 associated with these tasks, and one or moreparticular process engines responsible for execution of process 14. Forservice oriented tasks, descriptions may utilize Web ServicesDescription Language (WSDL) protocols. Each process 14 may represent oneor more user interface task flows, enterprise solution component taskflows, inter-enterprise process flows, or any other appropriateprocesses or task flows. Process model 114 a may specify allocation ofeach process 14 to a process controller, user interface controller, orenterprise-level workflow controller. Process model 114 a may alsoprovide for graphical or other simulation of processes 14.

[0106] (2) MDM Document Model

[0107] Document model 114 b provides the metadata for MDM documents thatare utilized in connection with processes 14. In one embodiment, MDMdocuments represent external cached representations of specific metadataelements within the underlying reference data model 114 d.

[0108] (3) MDM Forms Model

[0109] Forms model 114 c provides metadata describing forms associatedwith objects within reference data model 114 d. Forms may be importantfor efficient extraction of metadata elements from reference data model114 d and may be analogous to database views.

[0110] (4) MDM Reference Data Model

[0111] Reference data model 114 d represents the metadata describingreference data 22 stored within the core MDM reference data repository.This is the lowest level metadata representation contained within modellibrary 112. In one embodiment, reference data model 114 d may be anenterprise meta-model in Extensible Markup Language (XML) SoftwareDescription (XSD) format, which may separate instance data from metadatain a manner desirable for management and which back side data accesslayer 42 b may read directly from model library 112. It may be importantto synchronize changes to reference data model 114 d with any higherlevel constructs, such as forms model 114 c or document model 114 b.Synchronization of models 114 may be automatic or, if appropriate,studio 110 may flag the need for changes and direct an administrativeuser to assist in synchronizing models 114.

[0112] A generic reference data model for reference data 22 to be storedwithin the core MDM reference data repository may be constructed torepresent a synthesis of all applicable data elements, such as all dataelements associated with enterprises in the retail industry for example,and may be viewed as a superset of reference data models 114 d to beused in actual deployments of MDM system 4. The generic reference datamodel, and all reference data models 114 d ultimately derived from thegeneric reference data model, should be constructed for consistency andefficient management of reference data 22. In one embodiment, thegeneric reference data model may be captured as a document in anannotated RATIONAL ROSE object model.

[0113] (5) MDM Staging Data Model

[0114] Staging data model 114 e represents metadata describing thestructure of inbound and outbound staging tables 94 and 78,respectively, and also the mapping between reference data model 114 dand the staging table representation of the data within inbound andoutbound staging tables 94 and 78, respectively. Reference data model114 d may be a normalized data model derived from a generic referencedata model as described above. However, inbound data may reflectarbitrary schema that are inconsistent with reference data model 114 d.For inbound data, appropriate mappings (i.e. transformations) ofreference data model 114 d to source data models, such as an inboundstaging data model 114 e representing an arbitrary input data format foran external operational system 40, may be performed as inbound data isbeing stored in the core MDM reference data repository. Similarly,outbound data may need to be de-normalized for consumption asoperational data. For outbound data, appropriate mappings (i.e.transformations) of reference data model 114 d to target data models,such as an outbound staging data model 114 e representing a flat outputdata format for an external operational system 40, may be performed asreference data is being moved out of the core MDM reference datarepository

[0115] b. Business Rules Management Service

[0116] Referring again to FIG. 3, the business rules management servicemay provide for creation and maintenance of business rule elementsassociated with services 18, such as import validation rules, stagingtransformation rules, and general consistency rules associated with MDMsystem 4. The business rules management service may provide forrun-time-script-based rules or for association of design-time rulesobjects with MDM process workflows.

[0117] c. Process Controller

[0118] The process controller may represent a run-time process workflowcontroller for MDM system 4. As described above, process model 114 a mayspecify allocation of one or more processes 14 to the processcontroller, a user interface controller, or an enterprise-level workflowcontroller. In one embodiment, the process controller operates incooperation with any such user interface controller and any suchenterprise-level workflow controller.

[0119] d. MDM Structure Update Service

[0120] In one embodiment, MDM system 4 provides a mechanism to model itsstructure and a mechanism to automate a process to realize an extensionof that model in a physical deployment. The structure update service mayprovide for automated implementation of a model 114 that is created orchanged during the modeling process. The structure update service may beparticularly important with respect to the structure of inbound andoutbound staging areas 66 and 68, respectively. It may be necessary toinitially specify staging data model 114 e, the reference model tostaging area structure. In addition, it may be necessary to generateappropriate Structured Query Language (SQL) or changes to SQL tomaintain the state of staging areas 66 and 68 relative to staging datamodel 114 e. Without automation of these tasks using the structureupdate service, maintaining coordination of various elements of MDMsystem 4 would be a very intensive manual task. The structure updateservice may also provide for updating staging data model 114 e and othermodels 114, along with associated SQL, in response to updates providedwith enterprise solution components 6. Such structure updates may bedriven according to update description script documents providinginformation necessary for the structure update to automatically execute.

[0121] 2. Security Services

[0122] Naturally, only users with appropriate access should be permittedto view or manipulate reference data 22 within MDM system 4. Securityservices 34 b may be provided using a corresponding subsystem withinservices framework 32 designed to fulfill two primary responsibilities.The first responsibility is to control access to MDM system 4 itself.The second responsibility is to manage the structure of the securitymodel as applied to enterprise solution components 6. For thisresponsibility, services are provided to manage the security contextthat all enterprise solution components 6 will utilize, for example,through an LDAP repository whose master copy 82 resides withinoperational access area 80 of database 36. Security services 34 b mayinclude, without limitation: (1) authentication services, and (2)authorization services.

[0123] a. Authentication

[0124] Authentication services provide initial log-in security withrespect to enterprise solution components 6. Authentication ispreferably based on an organizational model for the enterprise toprovide a single log-in security context for all enterprise solutioncomponents 6.

[0125] b. Authorization

[0126] Authorization services provide layered, granular access tospecific services 18 or reference data 22 for an authenticated user.Authorization may be provided at two levels. The first level (Level 1)deals with access to enterprise solution components 6 represented byspecific applications or high level groups of services 18. The secondlevel (Level 2) deals with access to specific functions within anenterprise solution component 6. Field level authorization may behandled by particular enterprise solution components 6 themselves asappropriate. In the case of MDM system 4 itself, any requiredauthorization above Level 2 (i.e. Level 3 and higher) may need to beprovided within MDM system 4.

[0127] 3. General Services

[0128] General services 34 c may be provided using a correspondingsubsystem within services framework 32 and may include, withoutlimitation: (1) a change management service; (2) a lifecycle managementservice; (2) a group management service; and (4) an analytics andreporting service.

[0129] a. Change Management

[0130] The change management services provides an audit trail forchanges made to MDM system 4. For example, information may be keptregarding who made a change, at what time the change was made, andperhaps the value that was changed. The audit trail for changes shouldpreferably be implemented in such a fashion that the mechanism can beturned off for information not requiring change management or forchanges prior to configuration control, such as changes associated withinitial setup of data elements. Logical grouping of reference data 22may be important for many data management aspects, such as retrievingreference data 22 and making changes to reference data 22. Therefore, interms of granularity, in one embodiment change management is group-basedwith overrides at the group member level.

[0131] b. Lifecycle Management

[0132] As described above, reference data 22 stored within MDM system 4has an assigned state consistent with its use. The lifecycle managementservice allows for defining a lifecycle that describes the possiblestates for data elements, as well as a mechanism for managing themovement of data from one lifecycle state to another.

[0133] c. Group Management

[0134] Given the vast scope and scale of data that may potentiallyreside within MDM system 4, it is preferable that the overall strategyfor data management be based on logical groups of data rather thanindividual data elements. Logical grouping of reference data 22 may beimportant for many data management aspects, such as retrieving referencedata 22 and making changes to reference data 22. Although singleentities may be manipulated, many updates will typically occur withrespect to groups of entities. In one embodiment, the group aspect ofdata manipulation is built in from the foundation of MDM system 4.

[0135] d. Analytics and Reporting.

[0136] The health and status of a large data repository, such as thecore MDM reference data repository within database 36, is critical. Theanalytics and reporting service provides knowledge concerning whatreference data 22 is stored within the core MDM reference datarepository and the state of various system elements of MDM system 4.Although the types of analysis and associated reports will be specificto MDM system 4, general analysis and reporting tools may be used whereappropriate. Analytics may extend to a broad range of activitiessupported directly by this service or indirectly through management bythis service. Analytics may include clustering services forattributes/traits, decision support activities relating to entity datastored within the core MDM reference data repository, management ofparameter computation such as coordinating parameter computation usingan external engine, updating parameters such as lead times for items atparticular locations, and any other suitable analytics. Reports mayinclude change log activity, history traces for specific entities orgroups of entities, reports on production parameter sets includingtime-phased sets, calendar examination and reconciliation, reports onnew entities (such as new items) entered into the core MDM referencedata repository and dying entities (such as items) removed from the coreMDM reference data repository, and any other suitable reports.

[0137] 4. User Interface Services

[0138] 5. Data Access Services

[0139] Data access services 34 e may be provided using a correspondingsubsystem within services framework 32 to provide a key interfacebetween user interface layers, data management business rules, and theunderlying core MDM reference data repository within database 36. Dataaccess services 34 e may be included within data management framework 78described above with reference to FIG. 5. Since in one embodiment thepredominant view of reference data 22 is object-based, data accessservices 34 e may support a persistent mapping to underlying datastructures within database 36. Accordingly, in one embodiment, dataaccess services 34 e may incorporate the concept of a data cache, suchas cached data area 74 of database 36 described above, that provides amechanism to hold a copy of reference data 22 in cached data area 74 formanipulation while maintaining the state of reference data 22 in thecore MDM reference data repository of managed data area 72 as locked forread only access until the manipulation process has completed. Once acopy of reference data 22 is being held as cached data 76 within cacheddata area 74 during the manipulation process, the manipulation processsees only the state of cached data 76 within cached data area 74, whileother processes, services, and systems associated with MDM system 4 seethe true state of reference data 22 within managed data area 72 ratherthan an intermediate state reflecting the still incomplete manipulationprocess. Data access services 34 e may include, without limitation: (1)a persistence management service; and (2) a data access layer service.

[0140] a. Persistence Management

[0141] The persistence management service provides the logical mappingbetween the user view of reference data 22 and the underlying persistentobject model associated with reference data 22. The service provides formanaging the creation, update, and deletion of model instances,including appropriate memory-level caching of persistent objects.

[0142] b. Data Access Layer

[0143] The data access layer service provides the link between thelogical object model associated with reference data 22 and the physicalinstances of relational core MDM tables 96 in which the persistentobjects are held as reference data 22. The separation of the persistencelayer from a particular physical mapping layer allows for multiplephysical targets, which is especially useful when a distributed physicaldata model is required (e.g., in certain cases of parametermaintenance).

[0144] 6. Data Staging Services

[0145] Data staging services 34 e may be provided using a correspondingsubsystem within services framework 32, primarily to providesynchronization of inbound and outbound staging areas 66 and 68,respectively, with managed data area 72 of database 36. Data stagingservices 34 e may include, without limitation: (1) a data importservice; (2) a validation service; and (3) a syndication service.

[0146] a. Data Import

[0147] The data import service provides functions for moving data fromexternal sources into database 36. For example, the data import servicemight be used to move existing master data into database 36 for storageand later redistribution to one or more planning, execution, monitoring,or other enterprise solution components 6. Importing data includesmoving the inbound data into inbound staging area 84, validating andtransforming the inbound data where appropriate, and moving the inbounddata from inbound staging area 84 into the core MDM reference datarepository of managed data area 72 as reference data 22.

[0148] b. Validation

[0149] The validation service allows predefined, as well asuser-defined, validation rules to be applied to inbound data prior toinsertion into database 36. Validation rules may include basic valuetype rules, referential integrity rules, enterprise-specific businessrules, or any other suitable rule. In one embodiment, validation isselectable such that higher levels of validation may be used when aninbound data set is “dirty,” requiring more stringent validation, andlower levels of validation may be used when an inbound data set is“clean,” requiring less stringent validation.

[0150] c. Syndication

[0151] The syndication service, which essentially exports data fromdatabase 36 to planning, execution, monitoring, or other enterprisesolution components 6, may have two primary elements. The first elementprovides functions for synchronization of core MDM tables 96 withinmanaged data area 72 with outbound staging tables 100 within outboundstaging area 86, such that a valid snapshot of reference data 22 existsat all times within outbound staging tables 100, consistent with updatetransaction boundaries. The second element provides functions forschedule-based or demand-based movement of data from outbound stagingtables 100 to a target enterprise solution component 6.

[0152] IV. MDM Use Model

[0153]FIG. 8 illustrates an example MDM use model 130 for MDM system 4.In general, use model 130 describes how MDM system 4 will be used interms of where data is stored and how the data is accessed. In oneembodiment, the external operational systems 40 that interact with MDMsystem 4 view MDM system 4 as a reference data repository, not as anoperational data source. Accordingly, reference data 22 within core MDMreference data repository 132 may be synchronized and replicated tolocal persistent stores 134 of external operational systems 40 throughappropriate external access services 136 operating in association withone or both data access layers 42. Internal access services 138associated with managing reference data 22 within MDM system 4 may havedirect access to reference data 22 within core MDM reference datarepository 132. In contrast, operational services 140 of externaloperational systems 40, which are not associated with managing referencedata 22 within MDM system 4, may only access data within the associatedpersistent stores 134, never directly accessing reference data 22 withincore MDM reference data repository 132. Thus, in essence, MDM system 4may act as a secure system of record that is optimized in architectureand design for management of reference data 22 rather than operationaluse of reference data 22. Consuming services other than those related tomanaging reference data 22 are not permitted to directly accessreference data 22.

[0154] In one embodiment, key metrics to be considered in designing aphysical architecture in accordance with use model 130 may include,without limitation: (1) throughput performance; (2) query performance;(3) configuration flexibility; and (4) scale. Each of these metrics isdiscussed below in relation to appropriate physical characteristics ofan implementation of MDM system 4.

[0155] A. Throughput Performance

[0156] The primary use model for MDM system 4 features a centralizedmaster repository, core MDM reference data repository 132 of manageddata area 72 of database 36, for the core enterprise data, referencedata 22. In one embodiment, a goal is to shield core MDM reference datarepository 132 from operational loading while allowing for optimaldesign of external operational systems 40 that use reference data 22 inan operational mode. Accordingly, as described more fully above, usemodel 130 calls for synchronizing and replicating reference data 22 intolocal persistent stores 134 of external operational systems 40 that usereference data 22. This implies a physical architecture and design thatfacilitate outbound throughput performance for moving reference data 22from core MDM reference data repository 132 to target persistent stores134. If reference data 22 is being moved in quantity from externaloperation systems 40 into MDM system 4, then the physical architectureand design should preferably also support inbound throughputperformance. A primary design criterion following from the above is thatphysical data layer 54 should provide for as efficient access toreference data 22 as possible. It may be desirable to consider anyindirection layer that resides between core MDM tables 96 containingreference data 22, which may have a relational table structure, and theexterior representation of reference data 22, which may be an objectrepresentation.

[0157] B. Query Performance

[0158] The context for query performance is that of constructing viewsof reference data 22 for the MDM user interface or an analytics serviceinternal to MDM system 4, such as the analytics and reporting servicedescribed above with reference to FIG. 3. Such user interface andanalytics service queries are likely to be more filter-driven, lookingfor particular subsets of reference data 22 within a much larger rowcontext, than any SQL or other queries associated with the bulk exportof reference data 22 discussed above with respect to throughput. Thestructure of physical data layer 54 and the associated data access layerservice should be designed to handle potentially large numbers ofcomplex queries in a timely manner. Return of large and small queryresult row sets should be efficient independent of the target service(e.g., the user interface). Design criteria for query performance mayinclude low mean query response times at the database level, sufficientperformance under inbound loading involving a large number of inboundqueries, and minimal latency in the associated data access layerservice.

[0159] C. Configuration Flexibility

[0160] Configuration flexibility may be examined from both the user viewand the solution view. With respect to the user view, reference data 22contained in core MDM reference data repository 132 needs to be mappedto a particular data view that the enterprise requires. With respect tothe solution view, where the core metrics are typically performance inreplication and query performance, configuration flexibility may be lesscritical if not counter to those metrics. In general, it would be unwiseto change reference data model 94 d for each enterprise deployment,since that would imply reconfiguration of all interfaces from core MDMreference data repository 132 to local persistent stores 134 of externaloperational systems 40. A design criterion for configuration flexibilityis that reference data model 94 d should be stable from deployment todeployment and should represent a superset of anticipated reference data22 for any enterprise. Attainment of this state may be evolutionary overseveral deployments, but should be smoothly accomplished in a relativelyshort period of time without significant model redesign. If a user viewmapping configuration is required, it should preferably be at theoutermost layers of the design (i.e. close to the user interface ratherthan interior to data structures of core MDM reference data repository132).

[0161] D. Scalability

[0162] Core MDM reference data repository 132 may hold vast amounts ofreference data 22, particularly where MDM system 4 is associated with anexample retail enterprise having very large numbers of items, locations,or other entities. If attribute/trait data 22 e is utilized, whereseveral hundred trait attributes per entity may be common, the potentialfor vast amounts of reference data 22 is even higher. Thesecharacteristics may effectively lead to large table row counts, complexrelational joins, and the need for a dimension framework for referencedata 22. A design criterion for scalability, which is also related toboth throughput and query performance, is the ability to efficientlyhandle large row sets both when querying into the sets and when movingthe sets. These type of efficiencies generally come from well-designedand well-tuned relational tables specifically engineered forperformance-related metrics. A corollary is that the design shouldpreferably be capable of utilizing parallel database technology ifpossibly required to sufficiently scale in the enterprise environment.If the design cannot utilize parallel database technology, then theoption is lost when attempting to boost performance through deploymentconfiguration.

[0163] V. User Interface Architecture

[0164] There are several drivers for the architecture and design of auser interface for MDM system 4. A first driver is the dual types ofusers of MDM system 4; the administrative role user and the processparticipant role user. The first classification of user role isconcerned primarily with the administration of enterprise configurationinformation contained within MDM system 4, as well as the associated MDMmodels 114, which are realized physically in database 36. The secondclassification of user role is more concerned with viewing and enteringinformation associated with processes 14, such as new item introductionfor example. A modeling studio style interface may be more important tothe administrative role user, while well-designed view and entry screensequences may be more important to the process participant role user.User interface architecture and design requirements may be broken downalong these or other suitable lines. A second driver is the flexibilitythat is inherent in the MDM architecture. In one embodiment, bothreference data model 114 d and staging data model 114 e may be alteredat the time of deployment. This provides flexibility for MDM system 4 toaccommodate idiosyncrasies of the enterprise. Correspondingly, the userinterface architecture preferably accommodates these flexible models.For example, if a field is added or deleted within reference data model114 d or staging data model 114 e, a corresponding entry screen mayaccordingly adapt dynamically to the model change without the need forreprogramming.

[0165] VI. MDM Physical Architecture

[0166]FIG. 9 illustrates an example high level physical architecture 150for MDM system 4, which may be loosely mapped to logical businessarchitecture 10 described above with reference to FIG. 2 and logicaltechnical architecture 30 described above with reference to FIG. 3.

[0167] In one embodiment, MDM system 4 includes a web server 152, a MDMapplication server layer 154, an infrastructure services applicationserver layer 156, and a MDM database layer 158. Using a web browser orotherwise, a user associated with MDM system 4 may send a HypertextTransport Protocol (HTTP) or other request to web server 152 to performan appropriate operation. Web server 152 may communicate the request toone or more appropriate application servers within application serverlayer 154 to invoke one or more suitable applications 160. Applicationserver layer 154 may include one or more application servers supportingengines 140 a that provide process and service functions of MDM system4, supporting the MDM user interface 140 b, and supporting othersuitable applications 140. Infrastructure services application serverlayer 156 may include one or more application servers supporting frontside data access layer 42 a, back side data access layer 42 b, and asuitable enterprise-level workflow controller 142 that provides processand service functions associated with data access layers 42. Forexample, in one particular embodiment, front side data access layer 42 amay be implemented using a WEBMETHODS ENTERPRISE SERVER product, backside data access layer 42 b may be implemented in part using anINFORMATICA POWERCENTER product with an integratedExtract-Transform-Load (ETL) tool, and enterprise-level workflowcontroller 142 may be implemented using a WEBMETHODS BUSINESS INTEGRATORproduct.

[0168] In one embodiment, implementation of processes 14 may be sharedbetween enterprise-level workflow engine 162 of application server layer156 and applications 160 of application server layer 154. Services 12and associated services 34 may be provided primarily using applicationserver layer 154. Database layer 158 contains the actual physical datamodels 114, such as reference data model 114 d and staging data model114 e described above with reference to FIG. 7, with associated dataservices provided either at database layer 158 or application serverlayer 154.

[0169] VII. Example New Item Introduction Process

[0170]FIG. 10 illustrates an example new item introduction process 14provided within MDM system 4. Although introduction of a new item entityfor retail and associated vendor enterprises is described as an example,the present invention contemplates analogous or other introduction ofany suitable new entity for any suitable enterprise, whether or notspecifically described herein.

[0171] New item introduction is a very common and integral practice fordynamic value chain partners such as retailers and finished goodsvendors. The frequency of new items being introduced to a retailerassortment may vary from one to one thousand each week, depending uponthe retail segment and other factors. New item introduction may be themost important phase in the life cycle of an item. This process hastraditionally been highly paper intensive and has impeded the ability ofretailers and vendors to introduce items on a dynamic (i.e. day-to-day)basis, since there are thousands of variables, attributes, and otherfactors that may need to be considered in introducing a new item at theretailer shelf, from pricing to shelf-level execution. There is abusiness need for retailers to automate significant portions of the newitem introduction process, and to streamline integration with planning,execution, monitoring, and other enterprise component solutions, tointroduce new items with a shorter time-to-market, generate customerinterest, and gain market share. In one embodiment, with new itemintroduction process 14, MDM system 4 incorporates an embedded businessworkflow for new item introduction that enables an example retailenterprise to introduce a new item more quickly, more easily, with moreflexibility, and with more streamlined integration with planning,execution, monitoring, or other enterprise solution components 6 thanwith previous techniques.

[0172] A new item may be introduced in a number of different ways. Forexample, a vendor may introduce the new item to a retailer, a retailermay introduce the new item through item design (i.e. for private label),or a retailer and vendor may jointly decide to introduce the new item.Although there may be slight variations in these three methods of newitem introduction, since this example will focus on the workflowsinternal to the retailer, this description will include details of newitem introduction from a generic perspective. That is, the describedworkflows are generic in that they outline the processes that theretailer may go through, irrespective of whether the retailer introducesthe new item, the vendor introduces the new item, or the retailer andvendor jointly introduce the new item. These workflows may also beapplicable across all retailer formats (e.g., mass merchant, departmentstore, etc.) and all merchandise segments (hardlines, grocery,softlines, etc.).

[0173] As illustrated in FIG. 10, in one embodiment there are two majoraspects of new item introduction process 14: (1) a first sub-process 170involving introduction, review, acceptance, and rejection of the newitem, which may be analogized to the conception of a child; and (2) asecond sub-process 172 involving creation of the new item within theretailer for initiating merchandising, replenishment, and supply chainplanning and execution functions on the new item to make the new itemavailable at the shelf for sale to the customer, which may be analogizedto the birth of the child. First sub-process 170 may include, withoutlimitation: a vendor introduction component 174 (where the vendor isintroducing the new item), a retailer review component 176; a retailerrejection/modification component 178; a retailer approval component 180;and a vendor/retailer agreement finalization component 182. Secondsub-process 172 may include a vendor/retailer keying component 184, inwhich the vendor or retailer creates one or more appropriate masters forthe new item within database 36. Such masters may include, for example,an item master 186, an item-location master 188, and a vendor-itemmaster 190. After creation and storage of masters for the new itemaccording to execution of vendor/retailer keying component 184, legacysystems 192 and associated production databases 194 of the retailer orvendor may receive and recognize the new item for merchandising,replenishment, and supply chain planning and execution functions.

[0174] There may be many potential benefits of providing wholly orpartially automated processes 14 for new item introduction, entry,creation, and maintenance. For example, automation of the new itemintroduction process may provide one or more of the following benefits,without limitation: (1) providing the retailer with the ability tomerchandise and incorporate a new item into its assortments morequickly, thereby making the new item available to customers more quicklythan its competitors; (2) as a result of a shorter time-to-market fornew items, the retailer may considerably improve its chances ofincreasing sales and market share; (3) reduced labor costs andpaper-flow within and across various retail functions; (4) reducing oreliminating the possibility of keying errors, thereby reducing thepotential for human error; (5) providing tighter and more streamlinedintegration of the new item introduction process with planning,execution, monitoring, or other enterprise solution components 6,leading to better placement and replenishment of merchandise; and (6)efficiencies in planning and execution achieved through streamlinedintegration with new item introduction may be effectively leveraged toprovide the lowest shelf-landed cost to the end-customer. With respectto tighter and more streamlined integration, examples may include,without limitation: (1) data from a vendor's quote associated with a newitem may be automatically filled in for the retailer, no longer needingto be manually keyed in to finalize a contract with respect to the newitem; (2) Universal Product Code (UPC) number may be automaticallycreated for a new item once the new item has been created, no longerneeding to be manually keyed in; (3) a retailer legacy system may beautomatically checked to verify that a UPC number for a new item isassociated with a retailer product number, no longer needing to bemanually verified; and (4) in association with a merchandise planningsystem or other enterprise solution component 6, a product number for anew product may be automatically filled in for creation of a productassortment incorporating a new item, no longer needing to be manuallykeyed in.

[0175] New item introduction process 14 illustrated in FIG. 10 may bedescribed in more detail, from introduction of the new item by thevendor through maintenance of the item by the retailer in its systems.In one embodiment, new item introduction, entry, creation, andmaintenance associated with new item introduction process 14 within anexample retailer may be broken down into the following primarysub-processes, without limitation: (1) an initiation sub-process; (2) apreliminary planning sub-process; (3) an item entry, approval, initialforecast estimation, and replenishment initiation sub-process; (4) anitem setup, creation, activation, and initial replenishment sub-process;(5) an item merchandising and shelf execution setup sub-process; (6) anitem forecast entry and replenishment sub-process; (7) an ordermanagement and collaboration sub-process; (8) inbound(vendor-to-retailer) and outbound (retailer-to-location) supply chainplanning and execution sub-processes; (9) an item maintenancesub-process; and (10) an exceptions handling and management sub-process.

[0176] Although the present invention has been described with severalembodiments, a plethora of changes, substitutions, variations,alterations, and modifications may be suggested to one skilled in theart, and it is intended that the invention encompass all such changes,substitutions, variations, alterations, and modifications as fall withinthe spirit and scope of the appended claims.

What is claimed is:
 1. A system for centrally managing core enterprisereference data associated with an enterprise, comprising: a centralizedmaster repository containing the core enterprise reference data; aninternal services framework coupled to the centralized master repositoryand providing: a business process toolkit for managing models associatedwith the system, the business process toolkit comprising: a modellibrary containing data models; and one or more modeling services formodeling the system, its structure, and its components; and internalservices for managing the core enterprise reference data within thecentralized master repository, one or more of the internal serviceshaving direct access to the core enterprise reference data stored in thecentralized master repository for management purposes; and aninfrastructure services layer coupled to the centralized masterrepository and providing for bulk data transfers of core enterprisereference data between the centralized master repository and one or moreexternal operational systems according to one or more enterprise-levelbusiness workflows, the external operational systems being permittedindirect access to the core enterprise reference data stored in thecentralized master repository for operational purposes.
 2. The system ofclaim 1, wherein the models comprise one or more process modelsdescribing processes to be used for managing the core enterprisereference data stored in the centralized master repository, each processmodel describing for a corresponding process a flow of tasks to beperformed on the core enterprise reference data in connection with theprocess, one or more particular internal services associated with thesetasks, and one or more particular process engines responsible forexecution of the process.
 3. The system of claim 1, wherein the modelscomprise: a document model providing metadata for documents used inconnection with the processes to be used for managing the coreenterprise reference data stored in the centralized master repository,each document providing a representation of metadata elements within anunderlying core enterprise reference data model; a forms model providingmetadata describing forms associated with objects within the underlyingcore enterprise reference data model; and a core enterprise referencedata model representing metadata describing the core enterprisereference data stored in the centralized master repository, changes tothe core enterprise reference data model operable to be reflected in theforms and document models to synchronize these models with the coreenterprise reference data model.
 4. The system of claim 3, wherein theinternal services framework is operable to synchronize the forms anddocument models with the core enterprise reference data modelautomatically in response to changes to the core enterprise referencedata model.
 5. The system of claim 1, wherein the models comprise a coreenterprise reference data model representing metadata describing thecore enterprise reference data stored in the centralized masterrepository.
 6. The system of claim 5, wherein the core enterprisereference data model comprises an enterprise meta-model in ExtensibleMarkup Language (XML) Software Description Format (XSD) format thatseparates the metadata from instance data to facilitate metadatamanagement and that allows a data access layer within the infrastructureservices layer to read the metadata directly from the model library. 7.The system of claim 5, wherein the core enterprise reference data modelcomprises a generic core enterprise reference data model that representsa synthesis of data elements applicable for multiple actual deploymentsof the system and that comprises a superset of actual core enterprisereference data models to be used for multiple actual deployments of thesystem, each such actual core enterprise reference data model able to bederived from the generic core enterprise reference data model.
 8. Thesystem of claim 1, wherein the models comprise: a core enterprisereference data model representing metadata describing the coreenterprise reference data stored in the centralized master repository;and a staging data model that represents metadata describing structuresof inbound and outbound staging tables of a database providing thecentralized master repository and that provides mappings between thecore enterprise reference data model and a staging table representationof data within the inbound and outbound staging tables, the mappingscomprising: for inbound data a mapping of the core enterprise referencedata model to an inbound staging data model representing an arbitraryinput data format for an external operational system, the mapping to beperformed as inbound data is being stored in the centralized masterrepository as core enterprise reference data; and for outbound data amapping of the core enterprise reference data model to an outboundstaging data model representing a flat output data format for anexternal operational system, the mapping to be performed as coreenterprise reference data is being moved out of the centralized masterrepository as outbound data.
 9. The system of claim 1, wherein themodeling comprises one or more of: modeling structural aspects of adatabase that provides the centralized master repository; and modelingthe one or more enterprise-level business workflows.
 10. The system ofclaim 1, wherein the one or more modeling services comprise a structureupdate service providing a mechanism to create or modify a structuremodel and, in response, to automatically implement the created ormodified structure model in an actual deployment of the system.
 11. Thesystem of claim 1, wherein the external operational systems comprise oneor more of: external enterprise solution components associated with theenterprise; and external enterprises.
 12. A method for centrallymanaging core enterprise reference data associated with an enterprise,comprising: providing a centralized master repository containing thecore enterprise reference data; providing an internal services frameworkthat is coupled to the centralized master repository and provides: abusiness process toolkit for managing models associated with the system,the business process toolkit comprising: a model library containing datamodels; and one or more modeling services for modeling the centralizedmaster repository and associated structure and components; and internalservices for managing the core enterprise reference data within thecentralized master repository, one or more of the internal serviceshaving direct access to the core enterprise reference data stored in thecentralized master repository for management purposes; and providing aninfrastructure services layer that is coupled to the centralized masterrepository and provides for bulk data transfers of core enterprisereference data between the centralized master repository and one or moreexternal operational systems according to one or more enterprise-levelbusiness workflows, the external operational systems being permittedindirect access to the core enterprise reference data stored in thecentralized master repository for operational purposes.
 13. The methodof claim 12, wherein the models comprise one or more process modelsdescribing processes to be used for managing the core enterprisereference data stored in the centralized master repository, each processmodel describing for a corresponding process a flow of tasks to beperformed on the core enterprise reference data in connection with theprocess, one or more particular internal services associated with thesetasks, and one or more particular process engines responsible forexecution of the process.
 14. The method of claim 12, wherein the modelscomprise: a document model providing metadata for documents used inconnection with the processes to be used for managing the coreenterprise reference data stored in the centralized master repository,each document providing a representation of metadata elements within anunderlying core enterprise reference data model; a forms model providingmetadata describing forms associated with objects within the underlyingcore enterprise reference data model; and a core enterprise referencedata model representing metadata describing the core enterprisereference data stored in the centralized master repository, changes tothe core enterprise reference data model operable to be reflected in theforms and document models to synchronize these models with the coreenterprise reference data model.
 15. The method of claim 14, wherein theinternal services framework is operable to synchronize the forms anddocument models with the core enterprise reference data modelautomatically in response to changes to the core enterprise referencedata model.
 16. The method of claim 12, wherein the models comprise acore enterprise reference data model representing metadata describingthe core enterprise reference data stored in the centralized masterrepository.
 17. The method of claim 16, wherein the core enterprisereference data model comprises an enterprise meta-model in ExtensibleMarkup Language (XML) Software Description Format (XSD) format thatseparates the metadata from instance data to facilitate metadatamanagement and that allows a data access layer within the infrastructureservices layer to read the metadata directly from the model library. 18.The method of claim 16, wherein the core enterprise reference data modelcomprises a generic core enterprise reference data model that representsa synthesis of data elements applicable for multiple actual deploymentsand that comprises a superset of actual core enterprise reference datamodels to be used for multiple actual deployments, each such actual coreenterprise reference data model able to be derived from the generic coreenterprise reference data model.
 19. The method of claim 12, wherein themodels comprise: a core enterprise reference data model representingmetadata describing the core enterprise reference data stored in thecentralized master repository; and a staging data model that representsmetadata describing structures of inbound and outbound staging tables ofa database providing the centralized master repository and that providesmappings between the core enterprise reference data model and a stagingtable representation of data within the inbound and outbound stagingtables, the mappings comprising: for inbound data a mapping of the coreenterprise reference data model to an inbound staging data modelrepresenting an arbitrary input data format for an external operationalsystem, the mapping to be performed as inbound data is being stored inthe centralized master repository as core enterprise reference data; andfor outbound data a mapping of the core enterprise reference data modelto an outbound staging data model representing a flat output data formatfor an external operational system, the mapping to be performed as coreenterprise reference data is being moved out of the centralized masterrepository as outbound data.
 20. The method of claim 12, wherein themodeling comprises one or more of: modeling structural aspects of adatabase that provides the centralized master repository; and modelingthe one or more enterprise-level business workflows.
 21. The method ofclaim 12, wherein the one or more modeling services comprise a structureupdate service providing a mechanism to create or modify a structuremodel and, in response, to automatically implement the created ormodified structure model in an actual deployment.
 22. The method ofclaim 12, wherein the external operational systems comprise one or moreof: external enterprise solution components associated with theenterprise; and external enterprises.
 23. Software for centrallymanaging core enterprise reference data associated with an enterprise,the software being embodied in one or more computer-readable media andwhen executed using a computer system operable to: interact with acentralized master repository containing the core enterprise referencedata; provide an internal services framework that is coupled to thecentralized master repository and provides: a business process toolkitfor managing models associated with the system, the business processtoolkit comprising: a model library containing data models; and one ormore modeling services for modeling the centralized master repositoryand associated structure and components; and internal services formanaging the core enterprise reference data within the centralizedmaster repository, one or more of the internal services having directaccess to the core enterprise reference data stored in the centralizedmaster repository for management purposes; and provide an infrastructureservices layer that is coupled to the centralized master repository andprovides for bulk data transfers of core enterprise reference databetween the centralized master repository and one or more externaloperational systems according to one or more enterprise-level businessworkflows, the external operational systems being permitted indirectaccess to the core enterprise reference data stored in the centralizedmaster repository for operational purposes.
 24. The software of claim23, wherein the models comprise one or more process models describingprocesses to be used for managing the core enterprise reference datastored in the centralized master repository, each process modeldescribing for a corresponding process a flow of tasks to be performedon the core enterprise reference data in connection with the process,one or more particular internal services associated with these tasks,and one or more particular process engines responsible for execution ofthe process.
 25. The software of claim 23, wherein the models comprise:a document model providing metadata for documents used in connectionwith the processes to be used for managing the core enterprise referencedata stored in the centralized master repository, each documentproviding a representation of metadata elements within an underlyingcore enterprise reference data model; a forms model providing metadatadescribing forms associated with objects within the underlying coreenterprise reference data model; and a core enterprise reference datamodel representing metadata describing the core enterprise referencedata stored in the centralized master repository, changes to the coreenterprise reference data model operable to be reflected in the formsand document models to synchronize these models with the core enterprisereference data model.
 26. The software of claim 25, wherein the internalservices framework is operable to synchronize the forms and documentmodels with the core enterprise reference data model automatically inresponse to changes to the core enterprise reference data model.
 27. Thesoftware of claim 23, wherein the models comprise a core enterprisereference data model representing metadata describing the coreenterprise reference data stored in the centralized master repository.28. The software of claim 27, wherein the core enterprise reference datamodel comprises an enterprise meta-model in Extensible Markup Language(XML) Software Description Format (XSD) format that separates themetadata from instance data to facilitate metadata management and thatallows a data access layer within the infrastructure services layer toread the metadata directly from the model library.
 29. The software ofclaim 27, wherein the core enterprise reference data model comprises ageneric core enterprise reference data model that represents a synthesisof data elements applicable for multiple actual deployments and thatcomprises a superset of actual core enterprise reference data models tobe used for multiple actual deployments, each such actual coreenterprise reference data model able to be derived from the generic coreenterprise reference data model.
 30. The software of claim 23, whereinthe models comprise: a core enterprise reference data model representingmetadata describing the core enterprise reference data stored in thecentralized master repository; and a staging data model that representsmetadata describing structures of inbound and outbound staging tables ofa database providing the centralized master repository and that providesmappings between the core enterprise reference data model and a stagingtable representation of data within the inbound and outbound stagingtables, the mappings comprising: for inbound data a mapping of the coreenterprise reference data model to an inbound staging data modelrepresenting an arbitrary input data format for an external operationalsystem, the mapping to be performed as inbound data is being stored inthe centralized master repository as core enterprise reference data; andfor outbound data a mapping of the core enterprise reference data modelto an outbound staging data model representing a flat output data formatfor an external operational system, the mapping to be performed as coreenterprise reference data is being moved out of the centralized masterrepository as outbound data.
 31. The software of claim 23, wherein themodeling comprises one or more of: modeling structural aspects of adatabase that provides the centralized master repository; and modelingthe one or more enterprise-level business workflows.
 32. The software ofclaim 23, wherein the one or more modeling services comprise a structureupdate service providing a mechanism to create or modify a structuremodel and, in response, to automatically implement the created ormodified structure model in an actual deployment.
 33. The software ofclaim 23, wherein the external operational systems comprise one or moreof: external enterprise solution components associated with theenterprise; and external enterprises.
 34. A system for centrallymanaging core enterprise reference data associated with an enterprise,comprising: a centralized master repository containing the coreenterprise reference data; means coupled to the centralized masterrepository for providing: a business process toolkit for managing modelsassociated with the system, the business process toolkit comprising: amodel library containing data models; and one or more modeling servicesfor modeling the system, its structure, and its components; and internalservices for managing the core enterprise reference data within thecentralized master repository, one or more of the internal serviceshaving direct access to the core enterprise reference data stored in thecentralized master repository for management purposes; and means coupledto the centralized master repository for providing for bulk datatransfers of core enterprise reference data between the centralizedmaster repository and one or more external operational systems accordingto one or more enterprise-level business workflows, the externaloperational systems being permitted indirect access to the coreenterprise reference data stored in the centralized master repositoryfor operational purposes.
 35. A system for centrally managing coreenterprise reference data associated with an enterprise, comprising: acentralized master repository containing the core enterprise referencedata; an internal services framework coupled to the centralized masterrepository and providing internal services for managing the coreenterprise reference data within the centralized master repository, oneor more of the internal services having direct access to the coreenterprise reference data stored in the centralized master repositoryfor management purposes; and an infrastructure services layer coupled tothe centralized master repository and providing for bulk data transfersof core enterprise reference data between the centralized masterrepository and one or more external operational systems according to oneor more enterprise-level business workflows, the external operationalsystems being permitted indirect access to the core enterprise referencedata stored in the centralized master repository for operationalpurposes; one or more of the enterprise-level business workflows beingembedded within the system and being wholly or partially automated usingan enterprise-level workflow engine to wholly or partially automate oneor more associated enterprise-level business processes.
 36. The systemof claim 35, comprising: a logical process layer providing a context forimplementing and wholly or partially automating business configurationprocesses associated with the one or more enterprise-level businessworkflows; a logical service layer underlying the logical process layerproviding service functions enabling process tasks for the automatedbusiness configuration processes; and a logical data layer underlyingthe logical service layer providing base data models and physicalrepresentations for storing the core enterprise reference data forretrieval and use in connection with the business configurationprocesses and service functions.
 37. The system of claim 35, wherein thecentralized master repository incorporates a multi-dimensional databaseconstruct in which all the core enterprise reference data stored withinthe centralized master repository is represented as an attributeassociated with a point in n-dimensional entity space.
 38. The system ofclaim 37, wherein: the core enterprise reference data comprises masterdata representing core configuration data associated with entities ofthe enterprise; and a master for an entity is able to create,manipulate, navigate, view, and extract master data associated with theentity in a dimensional manner to support the one or moreenterprise-level business workflows.
 39. The system of claim 35, whereinthe infrastructure services layer further provides enterprise messagingbetween one or more of the internal services and the externaloperational systems according to operation of one or moreenterprise-level business workflows.
 40. The system of claim 35, whereinone automated enterprise-level business process comprises a new entityintroduction process.
 41. The system of claim 40, wherein the automatednew entity introduction process is an automated new item introductionprocess for a retail enterprise, the automated new item introductionprocess comprising adding new core enterprise reference data for the newitem to the centralized master repository, validating the new coreenterprise reference data for the new item, approving use of the newitem, and publishing the new item as available for use by the externaloperational systems.
 42. The system of claim 41, wherein the new item ispublished as available for use by the external operational systemsthrough replication for internal use by the external operational systemsrather than for direct access to the new item within the centralizedmaster repository by the external operational systems.
 43. The system ofclaim 41, wherein the automated new item introduction process comprises:creating and storing within the centralized master repository one ormore masters for the new item; and the external operational systemsreceiving and recognizing the new item for merchandising, replenishment,and supply chain planning and execution operations.
 44. The system ofclaim 43, wherein the one or more masters for the new item comprise anitem master, an item-location master, and a vendor-item master.
 45. Thesystem of claim 41, wherein the automated new item introduction processprovides streamlined integration with external operational systemsproviding merchandising, replenishment, and supply chain planning andexecution operations with respect to the new item.
 46. The system ofclaim 45, wherein the streamlined integration comprises one or more of:data from a vendor quote associated with the new item beingautomatically filled in, rather than needing to be manually keyed in, tofinalize a contract with respect to the new item; a Universal ProductCode (UPC) number being automatically created for the new item once thenew item has been created rather than needing to be manually keyed in; aretailer legacy system being automatically checked to verify that theUPC number for the new item is associated with a retailer product numberrather than needing to be manually verified; and a retailer productnumber for a new product being automatically filled in for creation of aproduct assortment incorporating the new item rather than needing to bemanually keyed in.
 47. A method for centrally managing core enterprisereference data associated with an enterprise, comprising: providing acentralized master repository containing the core enterprise referencedata; providing an internal services framework that is coupled to thecentralized master repository and providing internal services formanaging the core enterprise reference data within the centralizedmaster repository, one or more of the internal services having directaccess to the core enterprise reference data stored in the centralizedmaster repository for management purposes; and providing aninfrastructure services layer that is coupled to the centralized masterrepository and provides for bulk data transfers of core enterprisereference data between the centralized master repository and one or moreexternal operational systems according to one or more enterprise-levelbusiness workflows, the external operational systems being permittedindirect access to the core enterprise reference data stored in thecentralized master repository for operational purposes; one or more ofthe enterprise-level business workflows being embedded within the systemand being wholly or partially automated using an enterprise-levelworkflow engine to wholly or partially automate one or more associatedenterprise-level business processes.
 48. The method of claim 47,comprising: a logical process layer providing a context for implementingand wholly or partially automating business configuration processesassociated with the one or more enterprise-level business workflows; alogical service layer underlying the logical process layer providingservice functions enabling process tasks for the automated businessconfiguration processes; and a logical data layer underlying the logicalservice layer providing base data models and physical representationsfor storing the core enterprise reference data for retrieval and use inconnection with the business configuration processes and servicefunctions.
 49. The method of claim 47, wherein the centralized masterrepository incorporates a multi-dimensional database construct in whichall the core enterprise reference data stored within the centralizedmaster repository is represented as an attribute associated with a pointin n-dimensional entity space.
 50. The method of claim 49, wherein: thecore enterprise reference data comprises master data representing coreconfiguration data associated with entities of the enterprise; and amaster for an entity is able to create, manipulate, navigate, view, andextract master data associated with the entity in a dimensional mannerto support the one or more enterprise-level business workflows.
 51. Themethod of claim 47, wherein the infrastructure services layer furtherprovides enterprise messaging between one or more of the internalservices and the external operational systems according to operation ofone or more enterprise-level business workflows.
 52. The method of claim47, wherein one automated enterprise-level business process comprises anew entity introduction process.
 53. The method of claim 52, wherein theautomated new entity introduction process is an automated new itemintroduction process for a retail enterprise, the automated new itemintroduction process comprising adding new core enterprise referencedata for the new item to the centralized master repository, validatingthe new core enterprise reference data for the new item, approving useof the new item, and publishing the new item as available for use by theexternal operational systems.
 54. The method of claim 53, wherein thenew item is published as available for use by the external operationalsystems through replication for internal use by the external operationalsystems rather than for direct access to the new item within thecentralized master repository by the external operational systems. 55.The method of claim 53, wherein the automated new item introductionprocess comprises: creating and storing within the centralized masterrepository one or more masters for the new item; and the externaloperational systems receiving and recognizing the new item formerchandising, replenishment, and supply chain planning and executionoperations.
 56. The method of claim 55, wherein the one or more mastersfor the new item comprise an item master, an item-location master, and avendor-item master.
 57. The method of claim 53, wherein the automatednew item introduction process provides streamlined integration withexternal operational systems providing merchandising, replenishment, andsupply chain planning and execution operations with respect to the newitem.
 58. The method of claim 57, wherein the streamlined integrationcomprises one or more of: data from a vendor quote associated with thenew item being automatically filled in, rather than needing to bemanually keyed in, to finalize a contract with respect to the new item;a Universal Product Code (UPC) number being automatically created forthe new item once the new item has been created rather than needing tobe manually keyed in; a retailer legacy system being automaticallychecked to verify that the UPC number for the new item is associatedwith a retailer product number rather than needing to be manuallyverified; and a retailer product number for a new product beingautomatically filled in for creation of a product assortmentincorporating the new item rather than needing to be manually keyed in.59. Software for centrally managing core enterprise reference dataassociated with an enterprise, the software being embodied in one ormore computer-readable media and when executed using a computer systemoperable to: interact with a centralized master repository containingthe core enterprise reference data; provide an internal servicesframework that is coupled to the centralized master repository andprovides internal services for managing the core enterprise referencedata within the centralized master repository, one or more of theinternal services having direct access to the core enterprise referencedata stored in the centralized master repository for managementpurposes; and provide an infrastructure services layer that is coupledto the centralized master repository and provides for bulk datatransfers of core enterprise reference data between the centralizedmaster repository and one or more external operational systems accordingto one or more enterprise-level business workflows, the externaloperational systems being permitted indirect access to the coreenterprise reference data stored in the centralized master repositoryfor operational purposes; one or more of the enterprise-level businessworkflows being embedded within the software and being wholly orpartially automated using an enterprise-level workflow engine to whollyor partially automate one or more associated enterprise-level businessprocesses.
 60. The software of claim 59, operable to provide: a logicalprocess layer providing a context for implementing and wholly orpartially automating business configuration processes associated withthe one or more enterprise-level business workflows; a logical servicelayer underlying the logical process layer providing service functionsenabling process tasks for the automated business configurationprocesses; and a logical data layer underlying the logical service layerproviding base data models and physical representations for storing thecore enterprise reference data for retrieval and use in connection withthe business configuration processes and service functions.
 61. Thesoftware of claim 59, wherein the centralized master repositoryincorporates a multi-dimensional database construct in which all thecore enterprise reference data stored within the centralized masterrepository is represented as an attribute associated with a point inn-dimensional entity space.
 62. The software of claim 61, wherein: thecore enterprise reference data comprises master data representing coreconfiguration data associated with entities of the enterprise; and amaster for an entity is able to create, manipulate, navigate, view, andextract master data associated with the entity in a dimensional mannerto support the one or more enterprise-level business workflows.
 63. Thesoftware of claim 59, wherein the infrastructure services layer furtherprovides enterprise messaging between one or more of the internalservices and the external operational systems according to operation ofone or more enterprise-level business workflows.
 64. The software ofclaim 59, wherein one automated enterprise-level business processcomprises a new entity introduction process.
 65. The software of claim64, wherein the automated new entity introduction process is anautomated new item introduction process for a retail enterprise, theautomated new item introduction process comprising adding new coreenterprise reference data for the new item to the centralized masterrepository, validating the new core enterprise reference data for thenew item, approving use of the new item, and publishing the new item asavailable for use by the external operational systems.
 66. The softwareof claim 65, wherein the new item is published as available for use bythe external operational systems through replication for internal use bythe external operational systems rather than for direct access to thenew item within the centralized master repository by the externaloperational systems.
 67. The software of claim 65, wherein the automatednew item introduction process comprises: creating and storing within thecentralized master repository one or more masters for the new item; andthe external operational systems receiving and recognizing the new itemfor merchandising, replenishment, and supply chain planning andexecution operations.
 68. The software of claim 67, wherein the one ormore masters for the new item comprise an item master, an item-locationmaster, and a vendor-item master.
 69. The software of claim 65, whereinthe automated new item introduction process provides streamlinedintegration with external operational systems providing merchandising,replenishment, and supply chain planning and execution operations withrespect to the new item.
 70. The software of claim 69, wherein thestreamlined integration comprises one or more of: data from a vendorquote associated with the new item being automatically filled in, ratherthan needing to be manually keyed in, to finalize a contract withrespect to the new item; a Universal Product Code (UPC) number beingautomatically created for the new item once the new item has beencreated rather than needing to be manually keyed in; a retailer legacysystem being automatically checked to verify that the UPC number for thenew item is associated with a retailer product number rather thanneeding to be manually verified; and a retailer product number for a newproduct being automatically filled in for creation of a productassortment incorporating the new item rather than needing to be manuallykeyed in.